A Messy State of the Union: Taming the Composite State Machines of TLS

To appearInternational audienceImplementations of the Transport Layer Security (TLS) protocol must handle a variety of protocol versions and extensions, authentication modes, and key exchange methods. Confusingly, each combination may prescribe a different message sequence between the client and the server. We address the problem of designing a robust composite state machine that correctly multiplexes between these different protocol modes. We systematically test popular open-source TLS implementations for state machine bugs and discover several critical security vulnerabilities that have lain hidden in these libraries for years, and have now finally been patched due to our disclosures. Several of these vulnerabilities, including the recently publicized FREAK flaw, enable a network attacker to break into TLS connections between authenticated clients and servers. We argue that state machine bugs stem from incorrect compositions of individually correct state machines. We present the first verified implementation of a composite TLS state machine in C that can be embedded into OpenSSL and accounts for all its supported ciphersuites. Our attacks expose the need for the formal verifica- tion of core components in cryptographic protocol libraries; our implementation demonstrates that such mechanized proofs are within reach, even for mainstream TLS implementations

Implementing and Proving the TLS 1.3 Record Layer

International audienceThe record layer is the main bridge between TLS applications and internal sub-protocols. Its corefunctionality is an elaborate form of authenticated encryption: streams of messages for each sub-protocol(handshake, alert, and application data) are fragmented, multiplexed, and encrypted with optionalpadding to hide their lengths. Conversely, the sub-protocols may provide fresh keys or signal streamtermination to the record layer.Compared to prior versions, TLS 1.3 discards obsolete schemes in favor of a common construction forAuthenticated Encryption with Associated Data (AEAD), instantiated with algorithms such as AESGCMand ChaCha20-Poly1305. It differs from TLS 1.2 in its use of padding, associated data and nonces.It also encrypts the content-type used to multiplex between sub-protocols. New protocol features suchas early application data (0-RTT and 0.5-RTT) and late handshake messages require additional keysand a more general model of stateful encryption.We build and verify a reference implementation of the TLS record layer and its cryptographic algorithmsin F?, a dependently typed language where security and functional guarantees can be specifiedas pre- and post-conditions. We reduce the high-level security of the record layer to cryptographic assumptionson its ciphers. Each step in the reduction is verified by typing an F? module; for each stepthat involves a cryptographic assumption, this module precisely captures the corresponding game.We first verify the functional correctness and injectivity properties of our implementations of onetimeMAC algorithms (Poly1305 and GHASH) and provide a generic proof of their security given thesetwo properties. We show the security of a generic AEAD construction built from any secure onetimeMAC and PRF. We extend AEAD, first to stream encryption, then to length-hiding, multiplexedencryption. Finally, we build a security model of the record layer against an adversary that controls theTLS sub-protocols. We compute concrete security bounds for the AES_128_GCM, AES_256_GCM,and CHACHA20_POLY1305 ciphersuites, and derive recommended limits on sent data before re-keying.We plug our implementation of the record layer into the miTLS library, confirm that they interoperatewith Chrome and Firefox, and report initial performance results. Combining our functional correctness,security, and experimental results, we conclude that the new TLS record layer (as described in RFCsand cryptographic standards) is provably secure, and we provide its first verified implementation

Everest: Towards a Verified, Drop-in Replacement of HTTPS

The HTTPS ecosystem is the foundation on which Internet security is built. At the heart of this ecosystem is the Transport Layer Security (TLS) protocol, which in turn uses the X.509 public-key infrastructure and numerous cryptographic constructions and algorithms. Unfortunately, this ecosystem is extremely brittle, with headline-grabbing attacks and emergency patches many times a year. We describe our ongoing efforts in Everest (The Everest VERified End-to-end Secure Transport) a project that aims to build and deploy a verified version of TLS and other components of HTTPS, replacing the current infrastructure with proven, secure software. Aiming both at full verification and usability, we conduct high-level code-based, game-playing proofs of security on cryptographic implementations that yield efficient, deployable code, at the level of C and assembly. Concretely, we use F*, a dependently typed language for programming, meta-programming, and proving at a high level, while relying on low-level DSLs embedded within F* for programming low-level components when necessary for performance and, sometimes, side-channel resistance. To compose the pieces, we compile all our code to source-like C and assembly, suitable for deployment and integration with existing code bases, as well as audit by independent security experts. Our main results so far include (1) the design of Low*, a subset of F* designed for C-like imperative programming but with high-level verification support, and KreMLin, a compiler that extracts Low* programs to C; (2) an implementation of the TLS-1.3 record layer in Low*, together with a proof of its concrete cryptographic security; (3) Vale, a new DSL for verified assembly language, and several optimized cryptographic primitives proven functionally correct and side-channel resistant. In an early deployment, all our verified software is integrated and deployed within libcurl, a widely used library of networking protocols

A Verified Extensible Library of Elliptic Curves

International audienceIn response to increasing demand for elliptic curve cryptography, and specifically for curves that are free from the suspicion of influence by the NSA, new elliptic curves such as Curve25519 and Curve448 are currently being standardized, implemented, and deployed in major protocols such as Transport Layer Security. As with all new cryptographic code, the correctness of these curve implementations is of concern, because any bug or backdoor in this code can potentially compromise the security of important Internet protocols. We present a principled approach towards the verification of elliptic curve implementations by writing them in the dependently-typed programming language F* and proving them functionally correct against a readable mathematical specification derived from a previous Coq development. A key technical innovation in our work is the use of templates to write and verify arbitrary precision arithmetic once and for all for a variety of Bignum representations used in different curves. We also show how to use abstract types to enforce a coding discipline that mitigates side-channels at the source level. We present a verified F* library that implements the popular curves Curve25519, Curve448, and NIST-P256, and we show how developers can add new curves to this library with minimal programming and verification effort

A messy state of the union: taming the composite state machines of TLS

International audienceThe Transport Layer Security (TLS) protocol supports various authentication modes, key exchange methods, and protocol extensions. Confusingly, each combination may prescribe a different message sequence between the client and the server, and thus a key challenge for TLS implementations is to define a composite state machine that correctly handles these combinations. If the state machine is too restrictive, the implementation may fail to interoperate with others; if it is too liberal, it may allow unexpected message sequences that break the security of the protocol. We systematically test popular TLS implementations and find unexpected transitions in many of their state machines that have stayed hidden for years. We show how some of these flaws lead to critical security vulnerabilities, such as FREAK. While testing can help find such bugs, formal verification can prevent them entirely. To this end, we implement and formally verify a new composite state machine for OpenSSL, a popular TLS library

Dependent Types and Multi-Monadic Effects in F*

International audienceWe present a new, completely redesigned, version of F*, a language that works both as a proof assistant as well as a general-purpose, verification-oriented, effectful programming language. In support of these complementary roles, F* is a dependently typed, higher-order, call-by-value language with primitive effects including state, exceptions, divergence and IO. Although primitive, programmers choose the granularity at which to specify effects by equipping each effect with a monadic, predicate transformer semantics. F* uses this to efficiently compute weakest preconditions and discharges the resulting proof obligations using a combination of SMT solving and manual proofs. Isolated from the effects, the core of F* is a language of pure functions used to write specifications and proof terms---its consistency is maintained by a semantic termination check based on a well-founded order. We evaluate our design on more than 55,000 lines of F* we have authored in the last year, focusing on three main case studies. Showcasing its use as a general-purpose programming language, F* is programmed (but not verified) in F*, and bootstraps in both OCaml and F#. Our experience confirms F*'s pay-as-you-go cost model: writing idiomatic ML-like code with no finer specifications imposes no user burden. As a verification-oriented language, our most significant evaluation of F* is in verifying several key modules in an implementation of the TLS-1.2 protocol standard. For the modules we considered, we are able to prove more properties, with fewer annotations using F* than in a prior verified implementation of TLS-1.2. Finally, as a proof assistant, we discuss our use of F* in mechanizing the metatheory of a range of lambda calculi, starting from the simply typed lambda calculus to System F-omega and even micro-F*, a sizeable fragment of F* itself---these proofs make essential use of F*'s flexible combination of SMT automation and constructive proofs, enabling a tactic-free style of programming and proving at a relatively large scale